Contents 

Change History

1    Overview

The message definitions accessible from within this document have been defined to support a number of business processes, namely:

• Tracing patient details;
• Retrieving patient details;
• Confirming patient details;
• Allocating a NHS number for a set of patient details;
• Updating patient details (with death details, general administrative details or a change in consent status).

Use of Structured Address Format

There is an ongoing debate on the use of a defined structured address format. Until an IQAP decision has been reached on the appropriate structure the message format will use a 5 line unstructured format with Post Code and PAF key.

Use of Advance Trace

There is an Information Governance directive to meet Caldicott guidance  that when carrying out an Advanced Trace, no more information can be returned to the User than they are searching upon - until the number of returns is equal to one. It has been agreed for performance purposes that this will be managed at the local level.

Sensitivity Information Status

It is important that the sensitivity/confidentiality flags are dealt with in accordance with the IQAP Stop-noting MOU. The Successful Retrieval, Trace Match and NHS Number Confirmation messages return the 'Y', 'S', and 'B' values. These are for LSP system use only for managing behaviour around each status, they must not be displayed to the user.

NHAIS Registration Status (flag indicating no current Health Authority posting)

The NHAIS Registration status field (i.e. the flag used in some messages to indicate that a patient has no current Health Authority posting) will only be updatable by NSTS in P1. It has however been included in the PDS General Update message for extensibility purposes.

2    Storyboards

2.1    Trace

2.1.1    Individual Tracing

Example 1

Peter Parkinson has a consultation with Dr Jean Genome today to discuss the likelihood that he has inherited Parkinson’s disease.  Peter’s father died last year so Peter gives his permission for Dr Genome to look at his father John’s records.  Dr Genome enters John’s name, sex, date of birth, date of death and postcode onto the system and performs PDS Trace Query.

Example 2

Kari Kidd, a 2 year old who is failing to thrive, is taken by her mother Mary to a Paediatric Clinic following referral by their GP.  Upon arrival she is checked in by Jane the clerk.  Jane asks Mary basic details such as Kari’s full name, post code, sex and date of birth and uses them to do a PDS Trace Query. 

Example 3

Julie Partner, a diabetic since she was a child, is taken into the Accident and Emergency department of GHH in a confused state by her close friend John.  Tracy Record the receptionist does a PDS Trace Query using the details known by John which are Julie’s name, her date of birth and her gender.  Initially Tracy forgets to enter a date of birth into the query and gets a Query Failure message saying “Response failure due to inadequate, incorrect or invalid information in request”.  Further descriptive text in the response indicates that a mandatory item is missing.  Tracy repeats the query with all mandatory items but unfortunately this is insufficient to distinguish Julie from several other possible matches.  As PDS Trace Query can only return information where there is a single record matching, PDS returns a Query Failure message saying “Multiple match – number of entries exceed current operational limit for number of matches returned”

2.1.2    Batch Tracing

The local PAS system at the A&E in Exeter is about to become NCRS compliant. It has a number of entries for patients without NHS Numbers. In order to reconcile it’s database against the PDS it sends a batch of PDS Trace Query interactions, including the details of the patients without numbers. The PDS responds with a batch containing:

• PDS Trace Match interactions for all the exact matches it has found, with the local system is updated accordingly;

• Query Failure interactions for all cases where an exact match was not possible; these are noted and investigated individually.

2.2    Advanced Trace

Example 1

Amandeep Archive is processing medical records of dead patients in preparation for archive.  One of her tasks is to check that the information on the labels is correct.  Amandeep enters the address, sex, date of birth, date of death, NHS number, name (surname, initial and prefix) and GP code and requests no history.  She then performs a PDS Advanced Trace Query which returns a single match to the patient.  Amandeep checks the details and marks the file as checked and ready for archive.

Example 2

Dr Greg Practice is driving to work and witnesses a road traffic accident.  One casualty is unconscious but Dr Practice recognises him as Mr Wallace who came to see him last month.  Dr Practice assists the paramedics and provides as many demographic details for Mr Wallace as he can remember.

At A&E Tracey Record the receptionist performs a PDS Advanced Trace Query on Mr Wallace using sex, date of birth range and family name and initial and GP code provided by Dr Practice.  She also requests history to assist her in identifying Mr Wallace’s record.

Example 3

Amandeep Archive is processing medical records of dead patients in preparation for archive.  One of her tasks is to check that the information on the labels is correct.  One of the labels is smudged so Amandeep enters the address, the postcode with a wildcard, sex, date of birth, date of death, NHS number, name (surname, initial both with wildcards) and GP code and requests no history.  She then performs a PDS Advanced Trace Query.

Example 4

Eve Everywoman has moved out from her parent’s house in Scotland to a new apartment in London and soon after visits a local GP surgery to register for services.  She has enjoyed good health and has not visited her previous GP for many years.  Jack Puttin who is working on reception tries several PDS searches with PDS Advanced Trace Query using parts of Eve’s name, date of birth ranges, sex and various combinations of past addresses that Eve has resided in but PDS replies in each case with “No Match to a Service User record” within a Query Act Failed message.  This is because there has been no automatic bulk transfer of Scottish patient demographic details to the PDS database and Eve is simply not present within the system.

2.3    Trace Response

Example 1

See Trace Example 1.  Jean Genome’s search for Peter’s father John is successful and only one match is found.  A PDS Trace Match returns the NHS number, usual address, telephone numbers, current usual name, sex, date of birth, date of death, status of death notification and GP.  She then uses this information to access John’s records to see if any there is any clinical information relating to Parkinson’s disease.

Example 2

See Advanced Trace Example 2.  Tracey Record receives back a PDS Trace Match containing two matches to her PDS Advanced Trace Query for Mr Wallace.  Although Tracey requested history, neither record contained history.  Both records contain NHS number name, sex, date of birth and current GP but one record also contains a date of death.  Tracey is looking at the record for the live patient when one of the paramedics comes past with the news that Mr Wallace has come around and given his date of birth.  Tracey checks that the record she is viewing matches Mr Wallace’s date of birth and selects it.

Example 3

See Trace Example 2.  Jane receives back the PDS Trace Match for Kari Kidd showing the NHS number and name.  The other details (address, telecommunications and GP) have been suppressed because the Sensitivity Information Status (Confidentiality Code) is set to S.

Jane completes the check in process and sends Mary and Kari through for their consultation.

Example 4

See Advanced Trace Example 3.  Amandeep receives back the PDS Trace Match which contains two records.  The first record contains NHS number, name, sex, full date of birth, full date of death and GP.  The second record contains the NHS number and name and the remaining details are suppressed due to the Sensitivity Information Status being set.  Amandeep checks the first record and confirms that the details match those on the label and on the front page of the file.  Amandeep re labels the file and marks it as checked and ready for archive.

2.4    Retrieval Request and Result

2.4.1    Individual Retrieval

Example 1

Tracey Record is setting up a clinic list for Dr Richard Kildare.  For each patient on the list Tracey performs a PDS Retrieval Query requesting only the Serial Change number.  When a PDS Successful Retrieval is received with the patient Serial Change number this number is checked against the one held locally.  If they are the same (i.e. no updates have been made to the patient information on PDS) then Tracey adds the patient to the clinic list.

Example 2

Tracey Record is supervising the orthopaedic out patient clinic.  When each patient arrives, Tracey performs a PDS Retrieval Query and requests all person demographics including history.   She then checks the details returned in the PDS Successful Retrieval with the patient before sending the patient through to the waiting room.

Example 3

Adam Everyman has returned from his GP with a referral to see a consultant at Good Health Hospital on the following Monday.  Adam normally takes a close friend Sandra Proxy with him when he makes a trip to GHH but she isn’t available on that day.  Adam asks if she will cancel the appointment for him.  Sandra telephones Oliver Operator at the e-booking service who checks to see if Sandra is a valid proxy for Adam.  Oliver sends a PDS Retrieval Query to PDS including Adam’s NHS number and a parameter indicating that Proxy information is required.  Oliver is able to see from the results returned in the PDS Successful Retrieval message that Sandra is a valid proxy and therefore rearranges the appointment as requested.

Example 4

Delia Death receives notification from Dr Richard Kildare that a patient Ann Terminal has died in the hospital. Brenda performs a successful trace on Ann Terminal and then performs a PDS Retrieval Query requesting name, date of birth, date of death and sex.  Delia is able to see the results in the PDS Successful Retrieval message and from this she can see that the Date of Death has already been updated on PDS.

Example 5

GP Dr Clara Certified’s practice is no longer dispensing prescriptions to their patients.  Rita Ritalin has her regular appointment with Dr Certified today.  Dr Certified performs a PDS Retrieval Query requesting pharmacy details for Rita.  From the PDS Successful Retrieval message Dr Certified can see that Rita has the practice pharmacy as her nominated pharmacy.  During the consultation, Dr Certified explains that the practice no longer has a dispensary and suggests some alternative pharmacies to Rita. 

Example 6

Neville Nuclear visits his GP Clara Certified because of feeling tired.  Dr Certified completes a request form, takes a specimen of blood and sends it to the Pathology Laboratory at Good Health Hospital for a range of thyroid function tests.  Christopher Clerk the receptionist at the laboratory notices that the Laboratory Information Management System (LIMS) has no recorded address for Neville.  Christopher uses the NHS Number on the form to retrieve address details using the PDS Retrieval Query.  He is only interested in current address so does not ask for historic data.  Unfortunately he misreads a 5 for a 6.  PDS recognizes the check digit is now incorrect and issues a Query Act Failed message containing the code for “Response failure due to inadequate, incorrect or invalid information in request”.

2.4.2    Batch Retrieval

One of the consultants at the Optometry department at the RD&E Hospital in Devon is taken ill suddenly and looks likely to be off on long term sick for 3 months. The department manager immediately attempts to rearrange cover for her, but is forced to reschedule a number of appointments within that period. In order to inform all the patients affected it is decided that each one will be sent a letter explaining the situation and offered an alternate appointment. Their local system is NCRS compliant so in order to ensure that the letters go to the most up to date addresses, the administrator puts together a Batch of Retrieval Requests, with NHS Numbers, for all the patients affected. This is sent to the SPINE via a batch of PDS Retrieval Query interactions, which using the batching mechanism described in the Infrastructure manual. The SPINE returns a batch of PDS Successful Retrieval interactions in response, with details for each patient. The administrator then proceeds to update the local system where necessary and produce the letters required.

2.5    Confirm NHS number

Example 1

Tracey Record has a list of patients who need to be invited for follow up to Dr Richard Kildare’s clinic.  She sets up a list of NHS numbers and requests a PDS Confirm NHS Number Query for each number.  Tracey checks the details returned (NHS Number, address, name, sex, date of birth, date of death and death notification status) in the PDS NHS Number Confirmation messages initially to make sure the patients are still alive.  Where a date of death and a death status has been returned Tracey makes a note to follow these up later.  For all the other patients, Tracey uses the details returned in the PDS NHS Number Confirmation messages to set up a mail merge file.  Tracey then uses this mail merge file to issue an invitation letter to each patient for the clinic.

Example 2

Adam Everyman has a fall at home and visits his GP Dr Clara Certified for a consultation.  Dr Certified decides to send Adam to Good Health Hospital (GHH) hospital for an X-ray of his arm and arranges by telephone with Brenda Book the appointments clerk for Adam to attend the following morning.  Brenda enters the request into the Radiology Information System (RIS) using details she finds on the local Patient Management System (PMS).

The last time Adam visited the GHH was five years previously when he was assigned an NHS number.  Unfortunately this was set up manually as PDS was not operational and a mistake was made when the number was entered.

The RIS at GHH is configured to make sure that details on all patients expected to visit the Department on any particular day are as up to date as possible.  Prior to Alan’s appointment an PDS Confirm NHS Number Query is started by Brenda containing Adam’s patient identifier so that she can confirm the accuracy of the locally held data. Due to the error in the NHS number held by the local PMS, PDS can find no trace Adam’s record and returns an error in the Query Act Failed message indicating there was “No Match to a Service User record”.

2.6    Allocate NHS number

Example 1

Albert Ensten has returned to England after spending many years abroad. Albert has changed his name several times and can’t remember any addresses he had in England. He does remember being in hospital as a child in Devon. Amy Armstrong tries several PDS Advanced Trace Querys using some of the names Albert has used over the years but she can find no record for Albert. She decides to allocate an NHS Number and completes the on screen record with the information that Albert provides, address, telephone, name, sex, date of birth. She also asks Albert for his preferences and adds his preferred contact method, preferred written communication format and preferred language and interpreter required. She also marks the record to say that Albert has had previous NHS contact. This is transmitted to PDS as a PDS Allocate NHS Number Request and a NHS number is allocated and returned via the PDS Allocate NHS Number Response.

Example 2

Eve Everywoman has moved out from her parent’s house in Scotland to a new apartment in London and soon after visits her local PCT to register for NHS services. She has enjoyed good health and has not visited her previous GP for many years. Martha Puttin who is working on reception attempts several PDS Advanced Trace Querys but as she can find no previous record she decides to allocate a NHS number. She carefully completes the on screen record detailing Eve’s full name, address, date of birth, sex and telephone number as well as the GP practice number. Martha also marks the record to show that Eve has no previous NHS contact (in England).This is transmitted to PDS as a PDS Allocate NHS Number Request and a NHS number is allocated and returned via the PDS Allocate NHS Number Response.

2.7    Allocate NHS Number Failure

Eve Everywoman has moved out from her parent’s house in Scotland to a new apartment in London and soon after visits a local GP surgery to register for services.  She has enjoyed good health and has not visited her previous GP for many years.  Jack Puttin who is working on reception attempts a PDS Advanced Trace Query several times but as he can find no previous record he decides to allocate a NHS number.  He completes the on screen record detailing Eve’s full name, date of birth, sex and telephone number as well as the GP practice number. This is transmitted to PDS as a PDS Allocate NHS Number Request.  Unfortunately Jack omits to enter either a permanent or temporary address in the request and as this is a mandatory item PDS responds with an error in the Application Acknowledgement.  Additional text is also supplied detailing the problem.

2.8    General Update

2.8.1    Updating death information

A GP at the Good Health Medical Centre, Dr Clara Certified, is called out to see one of her patients, Mr. Ned Nuclear by his wife Nancy.  Ned has been suffering from carcinoma of the lung and despite chemotherapy his health has continued to decline.  After examining Ned carefully Clara pronounces him as dead.  She completes a death certificate for the family and after helping the family make arrangements Clara returns to the surgery.  She updates Ned’s PDS record using the PDS General Update Request including the date and time of death.  PDS responds with a code meaning the update was performed successfully within the PDS Successful Update Response message.

2.8.2    Updating general information

Example 1

Maria Sanchez registered for NHS services some time ago.   She has recently married and moved in to a new home with her husband and his children.  Maria visits her GP surgery and Jack Puttin retrieves Maria’s details and enters Maria’s new name, address and telephone numbers.  He also adds details of her step children as family/close contacts.  Maria has brought this information in written on paper so Jack asks Maria whether she would like to have a language or interpreter recorded on her record.  Maria agrees and Jack enters Maria’s language and that she would like an interpreter.  Jack updates Maria’s record using the PDS General Update Request and PDS responds with a PDS Successful Update Response message.

Example 2

Eve Everywoman registered for NHS services some time ago.  She works as an actress, has recently been in a very successful film and as a result she is now a well known celebrity.  On the advice of her legal advisors she writes to her local Primary Care Trust requesting that her records are updated.  She asks that her stage name of Sarah Showtime and her move to Marilyn Mansions are noted.   The Records Supervisor at the PCT, Maria Manager, performs a PDS General Update Request supplying Eve’s alias name and new address with a date effective taken from the letter. Unfortunately the date on the letter is the 30^th of February so PDS responds with an “Update failed” code within the Application Acknowledgement message plus additional text detailing the problem.

2.8.3    Updating consent information

Example 1

Julie Partner visits her GP with a persistent cough and cold.  It has been some time since Julie has visited the Good Health Medical Centre so Jack Puttin checks her records using PDS.  He notices that Julie is recorded as Implied Consent with regard to her records being shared with other NHS care professionals.  Jack asks her whether she has any objection to her medical records being shared in case she has to be referred.  Julie listens carefully to Jack about the benefits but decides that she does not want to give consent.  Jack uses the PDS General Update Request message to inform PDS of the change from Implied Consent to Express Dissent and explains to Julie how this could affect her NHS care in the future.  PDS responds with a PDS Successful Update Response message back to the requesting system.

3    Application Roles

The applications involved in the business processes listed above play specific roles. These, along with a description of the interactions associated with each role, are identified below.

3.1    Local Application Roles

3.1.1    PDS Query Placer - QUPA_AR010000UK10

The PDS Query Placer is the initiator of any type of query to the PDS. Types of query include: Trace, Advanced Trace, Retrieval and Confirm NHS Number.

3.1.2    PDS Registration Requester - PRPA_AR040000UK10

The PDS Registration Requester is the initiator of a request to allocate an identifier for a patient.

3.1.3    PDS Update Requester - PRPA_AR050000UK10

The PDS Update Requester is the person or organization responsible for requesting an update to a Service User record on the PDS.

3.2    PDS Application Roles

3.2.1    PDS Query Fulfiller - QUPA_AR020000UK10

The PDS Query Fulfiller responds to queries sent to the PDS. Types of query include: Trace, Advanced Trace, Retrieval and Confirm NHS Number.

3.2.2    PDS Registration Fulfiller - PRPA_AR060000UK10

The PDS Registration Fulfiller is the PDS acting in the role of provider of a newly allocated patient identifier for the set of patient details specified in a PDS NHS Number Allocation Request.

3.2.3    PDS Update Fulfiller - PRPA_AR080000UK10

The PDS Update Fulfiller is the PDS acting in the role of updater of information relating to a patient registered on the PDS.

4    Trigger Events

The trigger events which cause each interaction to be initiated are identified below.

4.1    PDS Trace Query Started - QUPA_TE010000UK10

The PDS Trace Query Started trigger event signals that a new trace query has been started in order to search for a patient given a suitable combination of name, DoB and postcode.

4.2    PDS Advanced Trace Query Started - QUPA_TE020000UK10

The PDS Advanced Trace Query Started trigger event signals that a new advanced trace query has been started in order to search for a patient using a wider range of search parameters that in a PDS Trace Query.

4.3    PDS Trace Query Successful - QUPA_TE030000UK10

The PDS Trace Query Successful trigger event signals that the result of a PDS Trace Query is that a single identifiable patient has been found on the PDS, or that the result of a PDS Advanced Trace Query is that one or more (but not more than a limit constrained by the PDS) identifiable patients were found on the PDS.

4.4    PDS Retrieval Query Started - QUPA_TE040000UK10

The PDS Retrieval Query Started trigger event signals that a new request to retrieve a patient's demographic details has been made.

4.5    PDS Retrieval Query Successful - QUPA_TE050000UK10

The PDS Retrieval Query Successful trigger event signals that the result of a PDS Retrieval Query is that the identified patient has been found on the PDS, and that demographic details are being returned for that patient.

4.6    PDS Confirm NHS Number Query Started - QUPA_TE060000UK10

The PDS Confirm NHS Number Query Started trigger event signals that a new request to confirm a patient's NHS number has been made.

4.7    PDS NHS Number Confirmed - QUPA_TE070000UK10

The PDS NHS Number Confirmed trigger event signals that the result of a PDS Confirm NHS Number Query is that the identified patient has been found on the PDS, and that some demographic details are being returned for that patient.

4.8    PDS NHS Number Allocation Request Started - PRPA_TE040000UK10

The PDS NHS Number Allocation Request Started trigger event signals that a new request to allocate a NHS number for a patient has been made.

4.9    PDS NHS Number Allocation Request Completed - PRPA_TE060000UK10

The PDS NHS Number Allocation Request Completed trigger event signals that the result of a PDS NHS Number Allocation Request is that a newly allocated NHS number is being returned for that patient.

4.10    PDS Successful Update Response - PRPA_TE150000UK10

The PDS Successful Update Response trigger event signals that the result of a PDS Update is that the details have been updated on PDS.

4.11    PDS General Update Started - PRPA_TE160000UK30

The PDS General Update Started trigger event signals that some patient details, possibly including consent and / or death information, have been changed, corrected or some new details are available, and are to be recorded on the PDS.

5    Interaction Diagrams

This section provides diagrammatic representation of which interactions are related to which application roles.

5.1    Trace Query interactions

5.2    Retrieval Query interactions

5.3    Confirm NHS Number Query interactions

5.4    NHS Number Allocation interactions

5.5    General Update interactions

6    Interactions

6.1    PDS Trace Query Started - QUPA_IN010000UK32

The PDS Trace Query Started interaction occurs when a request to trace a patient on the PDS is started. The PDS Query Placer sends a PDS Trace Query, with the various patient details, to the PDS Query Fulfiller.

This interaction may be batched using the generic batching mechanism described in the Infrastructure domain.

Click here for details of this mechanism.

Receiver Responsibilities

NB: The interactions listed in the above table can be batched in response to a batch of PDS Trace Query Started interactions, with one or other or both types of interaction being present in the batched response.

6.2    PDS Advanced Trace Query Started - QUPA_IN020000UK31

The PDS Advanced Trace Query Started interaction occurs when a request to trace a patient on the PDS using advanced trace mechanisms is started. The PDS Query Placer sends a PDS Advanced Trace Query, with the various patient details, to the PDS Query Fulfiller.

Receiver Responsibilities

6.3    PDS Trace Query Successful - QUPA_IN030000UK32

The PDS Trace Query Successful interaction occurs when a request to trace a patient on the PDS results in a successful match. The PDS Query Fulfiller sends a PDS Trace Match, with a number of data fields relating to the patient or patients, to the PDS Query Placer.

This interaction may be batched in response to a batch of PDS Trace Query Started interactions, using the generic batching mechanism described in the Infrastructure domain. Click here for details of this mechanism.

6.4    PDS Retrieval Query Started - QUPA_IN040000UK32

The PDS Retrieval Query Started interaction occurs when a request to retrieve patient details from the PDS is started. The PDS Query Placer sends a PDS Retrieval Query, with the patient's identifier, to the PDS Query Fulfiller.

This interaction may be batched using the generic batching mechanism described in the Infrastructure domain.

Click here for details of this mechanism.

Receiver Responsibilities

NB: The interactions listed in the above table can be batched in response to a batch of PDS Retrieval Query Started interactions, with one or other or both types of interaction being present in the batched response.

6.5    PDS Retrieval Query Successful - QUPA_IN050000UK32

The PDS Retrieval Query Successful interaction occurs when a request to retrieve patient details from the PDS results in a successful match on the patient identifier and all criteria for retrieving the data are met. The PDS Query Fulfiller sends a PDS Successful Retrieval, with a number of data fields, to the PDS Query Placer.

This interaction may be batched in response to a batch of PDS Retrieval Query Started interactions, using the generic batching mechanism described in the Infrastructure domain. Click here for details of this mechanism.

6.6    PDS Confirm NHS Number Query Started - QUPA_IN060000UK30

The PDS Confirm NHS Number Query Started interaction occurs when a request to confirm patient details from the PDS is started. The PDS Query Placer sends a PDS Confirm NHS Number Query, with a set of details relating to the patient, to the PDS Query Fulfiller.

Receiver Responsibilities

6.7    PDS NHS Number Confirmed - QUPA_IN070000UK30

The PDS NHS Number Confirmed interaction occurs when a request to confirm patient details from the PDS is successful. PDS Query Fulfiller sends a PDS NHS Number Confirmation, with a number of data fields to reduce the need for further queries following confirmation, to the PDS Query Placer.

6.8    PDS NHS Number Allocation Request Started - PRPA_IN040000UK30

The PDS NHS Number Allocation Request Started interaction occurs when a request to allocate an identifier for a patient is started. The PDS NHS Number Allocation Requester sends a PDS Allocate NHS Number Request, with a set of details relating to the patient, to the PDS NHS Number Allocation Fulfiller.

Receiver Responsibilities

6.9    PDS NHS Number Allocation Request Completed - PRPA_IN060000UK30

The PDS NHS Number Allocation Request Completed interaction occurs when a request to allocate an identifier for a patient has completed. The PDS NHS Number Allocation Fulfiller sends a PDS Allocate NHS Number Response to the PDS NHS Number Allocation Requester providing a newly allocated NHS number.

6.10    PDS Successful Update Response - PRPA_IN150000UK30

The PDS Successful Update Response interaction occurs when an update request to PDS has been accepted. The PDS Update Tracker sends a PDS Successful Update Response to the PDS Update Informer.

6.11    PDS General Update Started - PRPA_IN160000UK30

The PDS General Update Started interaction occurs when a change in the patient's administrative details, possibly including consent and death information, is recorded. The PDS Update Requester sends a PDS General Update Request, with the changed, corrected or new details to the PDS Update Fulfiller.

Receiver Responsibilities

7    Message Definitions

This section describes each of the message types used amongst the various interactions. For each message type, links are provided to detailed documentation:

• A diagrammatic representation of the message model;
• A table view of each data field used within the message containing detailed guidance on how each field is populated together with examples;
• The schema for the message type;
• One or more example messages conforming to the schema and guidance.

7.1    PDS Trace Query - QUPA_MT010101UK13

       Example 1

Features of this example include:

• Search on full postcode;
• Search on sex;
• Search on full date of birth;
• Search on full date of death;
• Search on family name and first given name.

         Example 2

Features of this example include:

• Search on PAF Key;
• Search on sex;
• Search on full date of birth;
• Search on family name and first given name.

7.2    PDS Advanced Trace Query - QUPA_MT020101UK14

The Advanced Trace supports tracing based on the following parameters:

• Family Name/Surname;

• Given Name/First Name;

• Other Given Name;

• Date of Birth or Date of Birth Range;

• Date of Death or Date of Death range;

• Sex;

• Address Lines 1-5;

• Postcode;

• PAF Key;

• Primary Care Data.

The following parameters are also required:

• Historic Data Flag;

• Search Type (Alphanumeric or Algorithmic).

For Alphanumeric searches the mandatory data items are:

• Family Name/Surname;

• Sex;

• Search Type = 1.

The Name details will be compared to all name types (i.e. usual, previous, preferred, alias).

The following details are ignored: name suffix, title, Person Name Classification.

The address details will be compared to all addresses (usual, correspondence, temporary). The Address Association Type if given is not used.

The Alphanumeric search does not cater for misspellings or typographical errors. However, it is possible to use a wildcard character (*) with at least two preceding characters.

Partial postcodes may be used for Alphanumeric searches by using a part of the postcode and a wildcard character (*).
 

For Algorithmic searches the following combinations have been proposed. Note that these may be subject to refinement:
 

1. Family Name/Surname, Given Name/Forename, Date of Birth (or Date of Birth Range).  In this case name transposition will be carried out if no matches are found on the first pass.

2. Family Name/Surname, Sex, Date of Birth, Postcode. 

3. Given Name/Forename, Sex, Date of Birth, Postcode.

4. Family Name/Surname, PAF Key

The name details will be compared to all name types (i.e. usual, previous, preferred, alias).

The following details are ignored name suffix, title, Person Name Classification. 

The address details will be compared to all addresses (usual, correspondence, temporary).  The Address Association Type if given is not used.

       Example 1

Features of this example include:

• No historic data required;
• Alphanumeric search required;
• Search on full address;
• Search on sex;
• Search on full date of birth;
• Search on full date of death;
• Search on NHS number;
• Search on family name, initial and prefix;
• Search on national GP code.

        Example 2

Features of this example include:

• Historic data required;
• Algorithmic search required;
• No address;
• Search on sex;
• Search on date of birth range with partial dates;
• Search on usual family name with initial;
• Search on national GP Practice code.

        Example 3

Features of this example include:

• No historic data required;
• Algorithmic search required;
• Usual address with a postcode having a wildcard (*);
• Search on sex;
• Search on full date of birth;
• Search on full date of death;
• Search on NHS number;
• Search on usual family name with initial, both having wildcards (*);
• Search on national GP Practice code.

7.3    PDS Trace Match - PRPA_MT230101UK13

Return match after either a trace or advanced trace search using input parameters.

Single match responses are to a high confidence level. Matching algorithms will deliver a quantitative matching level and PDS policy may vary on the level required for a trusted match. Trace can only return a single match, while advanced trace can return multiple matches.

       Example 1

Features of this example include:

• Single match to a trace (not advanced trace) query;
• Return of NHS number;
• Return of usual address;
• Return of current telephone numbers;
• Return of current usual name;
• Return of sex;
• Return of full date of birth;
• Return of full date of death;
• Return of death notification status;
• Return of current registered GP.

        Example 2

Features of this example include:

• Multiple matches to an advanced trace query;
• Returns for first match are:

• Return of NHS number;

• Return of current usual name;

• Return of sex;

• Return of full date of birth;

• Return of full date of death;

• Return of current registered GP.

• Returns for second match are:

• Return of NHS number;

• Return of current usual name;

• Return of sex;

• Return of full date of birth;

• Return of current registered GP.

        Example 3

Features of this example include:

• Single match to a trace (not advanced trace) query;
• Return of NHS number;
• Return of current usual name;
• Return of sensitivity information status (confidentiality code);
• Return of no further details as sensitivity conditions apply.

       Example 4

Features of this example include:

• Multiple matches to an advanced trace query;
• Returns for first match are:

• Return of NHS number;

• Return of current usual name;

• Return of sex;

• Return of full date of birth;

• Return of full date of death;

• Return of current registered GP.

• Returns for second match are:

• Return of NHS number;
• Return of current usual name;
• Return of sensitivity information status (confidentiality code);
• Return of full date of birth.

7.4    PDS Retrieval Query - QUPA_MT030101UK30

A request for patient details to PDS. The retrieval message supports requests for any or all of the retrievable fields. A history flag is used to indicate whether or not historic data is to be returned in addition to current data.

        Example 1

Features of this example include:

• Patient identified by NHS number;
• Historic data flag not set (i.e. no history required);
• Retrieve Call Centre Data details only.

       Example 2

Features of this example include:

• Patient identified by NHS number;
• Historic data flag set;
• Retrieve full person demographics.

        Example 3

Features of this example include:

• Patient identified by NHS number;
• Historic data flag set;
• Retrieve proxy details only.

       Example 4

Features of this example include:

• Patient identified by NHS number;
• Historic data flag not set (i.e. no history required);
• Retrieve current usual name;
• Retrieve date of birth, date of death, sex.

       Example 5

Features of this example include:

• Patient identified by NHS number;
• Historic data flag not set (i.e. no history required);
• Retrieve pharmacy details only.

7.5    PDS Successful Retrieval - PRPA_MT040101UK31

A general class of retrieval message containing the maximum permissible fields able to be retrieved.

        Example 1

Features of this example include:

• Response to retrieval query 1 above;
• Patient identified by NHS number;
• Retrieval of System Change Number only.

        Example 2

Features of this example include:

• Response to retrieval query 2 above;
• Patient identified by NHS number;
• Retrieval of full person demographics:
  • superceded IDs;
  • usual name;
  • other names;
  • birth date;
  • death date + death notification status;
  • sex;
  • consent details;
  • confidentiality + NHAIS posting details.
• Retrieval of System Change Number (always returned by PDS).

        Example 3

Features of this example include:

• Response to retrieval query 3 above;
• Patient identified by NHS number;
• Retrieval of full proxy details.
• Retrieval of System Change Number (always returned by PDS).

        Example 4

Features of this example include:

• Response to retrieval query 4 above;
• Patient identified by NHS number;
• Retrieval of current usual name;
• Retrieval of date of birth, date of death, sex.
• Retrieval of System Change Number (always returned by PDS).

        Example 5

Features of this example include:

• Response to retrieval query 5 above;
• Patient identified by NHS number;
• Response indicates patient found but no data found.
• Retrieval of System Change Number (always returned by PDS).

7.6    PDS Confirm NHS Number Query - QUPA_MT040101UK13

To confirm that the PDS Service User Record for this NHS Number is consistent with the locally-held patient details as indicated by the unique version control number.

Note both PDS and NHAIS temporary NHS Numbers may also be used.

Features of this example include:

• Patient identified by NHS number.

7.7    PDS NHS Number Confirmation - PRPA_MT090101UK14

A positive response to the confirm NHS Number query. A number of PDS data fields are output as part of the response, to reduce the need for additional queries immediately following confirmation.

        Example 1

Features of this example include:

• Response to NHS Number Confirmation query 1 above;
• Patient identified by NHS number;
• Usual address returned;
• Usual name returned;
• Sex, date of birth, date of death and death notification status returned
• Current registered GP returned;
• Consent details returned;
• System change number returned.

        Example 2

Features of this example include:

• Alternative response to NHS Number Confirmation query 1 above;
• Patient identified by NHS number;
• Limited details returned due to sensitivity conditions applying to the Service User record.

7.8    PDS Allocate NHS Number Request - PRPA_MT100101UK13

To make a request on PDS to allocate a NHS Number. The minimum set of data items judged adequate to make a NHS Number allocation will vary according to PDS operational policy.

Minimum mandatory details are: name, Date of Birth, gender and a permanent or temporary address.

        Example 1

Features of this example include:

• Usual address;
• Telephone, mobile and e-mail communications;
• Usual name;
• Sex;
• Full birth date;
• Preferred contact method;
• Preferred written communication format
• Registered GP Practice;
• Preferred language where not English + interpreter required indicator;
• Indication of previous NHS contact;
• NHAIS and NHAIS user as registering authority.

        Example 2

Features of this example include:

• Usual address;
• Telephone;
• Usual name;
• Sex;
• Partial birth date;
• Registered GP Practice;
• Indication of no previous NHS contact;
• PCT as registering authority.

7.9    PDS Allocate NHS Number Response - PRPA_MT110101UK12

The Result message contains the NHS Number if the request has been successful.

Features of this example include:

• Response to allocate NHS Number Request example 2 above;
• NHS number allocated.

7.10    PDS Successful Update Response - PRPA_MT180101UK12

Used in response to a message which updates the PDS to indicate that the update has been successful and provided the nature of that success.

Features of this example include:

• System Change Number returned.

7.11    PDS General Update Request - PRPA_MT240101UK30

This update allows modification of all updateable PDS data fields, including consent and death information.

        Example 1

Features of this example include:

• Examples of altering each type of data that can be altered;
• System Change Number provided in update.

       Example 2

Features of this example include:

• Examples of adding each type of data that can be added;
• System Change Number provided in update.

       Example 3

Features of this example include:

• Examples of removing each type of data that can be removed;
• System Change Number provided in update.

8    Glossary of Terms

9    Changes for v3.2

9.1    Changes to Specific Messages

9.1.1    PDS Successful Retrieval - PRPA_MT040101UK31

CR-0676:    PDS Successful Retrieval -  PRPA_MT040101UK30 is reversioned to PRPA_MT040101UK31. This is because a change has been made to the cardinality of pertinentInformation which leads to SerialChangeNumber. The Serial Change Number will always be supplied, so the cardinality has been changed from 0..1 to 1..1. Tabular view, schema and XML examples also reversioned accordingly.

9.2    Changes to Specific Interactions

9.2.1    PDS Retrieval Query Started - QUPA_IN040000UK32

PDS Retrieval Query Started -  QUPA_IN040000UK31 is reversioned to QUPA_IN040000UK32 because of the following changes: the Query Successful receiver responsibility interaction has been updated to QUPA_IN050000UK32 (CR-0676); the Transmission Wrapper has been changed from Send Message Payload (optional sender/receiver) to Send Message Payload (CR-0707); the Query Failed receiver responsibility interaction has been changed from Query Act Failed (optional sender/receiver) to Query Act Failed (CR-0707).

9.2.2    PDS Retrieval Query Successful - QUPA_IN050000UK32

PDS Retrieval Query Successful -  QUPA_IN050000UK31 is reversioned to QUPA_IN050000UK32 because of the following changes: the payload has been updated to PRPA_MT040101UK31 (CR-0676); the Transmission Wrapper has been changed from Application Acknowledgement (optional sender/receiver) to Application Acknowledgement (CR-0707).

9.2.3    PDS Trace Query Started - QUPA_IN010000UK32

CR-0707:    PDS Trace Query Started -  QUPA_IN010000UK31 is reversioned to QUPA_IN010000UK32 because the Transmission Wrapper has been changed from Send Message Payload (optional sender/receiver) to Send Message Payload, and the Query Failed receiver responsibility interaction has been changed from Query Act Failed (optional sender/receiver) to Query Act Failed.

9.2.4    PDS Trace Query Successful - QUPA_IN030000UK32

CR-0707:    PDS Trace Query Successful -  QUPA_IN030000UK31 is reversioned to QUPA_IN030000UK32 because the Transmission Wrapper has been changed from Application Acknowledgement (optional sender/receiver) to Application Acknowledgement.

9.2.5    PDS Advanced Trace Query Started - QUPA_IN020000UK31

CR-0707:    PDS Advanced Trace Query Started -  QUPA_IN020000UK30 is reversioned to QUPA_IN020000UK31 because the Query Successful receiver responsibility interaction has been updated to QUPA_IN030000UK32.

9.3    Changes to Interaction Diagrams

9.3.1    Retrieval Query interactions

CR-0676:     QUPA_IN040000UK31 is reversioned to QUPA_IN040000UK32 and QUPA_IN050000UK31 is reversioned to QUPA_IN050000UK32 as outlined above.

9.3.2    Trace Query interactions

CR-0707:     QUPA_IN010000UK31 is reversioned to QUPA_IN010000UK32, QUPA_IN020000UK30 is reversioned to QUPA_IN020000UK31 and QUPA_IN030000UK31 is reversioned to QUPA_IN030000UK32 as outlined above.